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Background of the Invention 

1 Field of the Invention 

The present invention relates generally to incremental software updating, and more 
15 specifically to a system and method for using an automated, multi-tiered approach to performing 
incremental software updates. 

9 Descri ption of background Art 

Some computer software publishers update their software "applications" (computer 
20 programs and data files associated with the programs) frequently. For some types of software 
applications, such as virus protection software, these updates are particularly frequent. Virus 
protection software applications are designed to detect computer viruses on a computer system, 
and may also remove viruses which are found. An example of such a software application is 
Norton Anti-Virus, published by Symantec Corporation of Cupertino, California. Because these 



25 virus protection software applications rely on data about specific viruses, and new viruses are 
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constantly being written to avoid current virus detection capabilities, it is necessary to update 
virus protection software applications on a regular basis to account for the newest viruses. 
Frequent updating of data files is also necessary for some database publishers, who must put up- 
to-date information in their databases, and remove obsolete information therefrom. Periodic 
5 updating of general software applications to expand capabilities and eliminate "bugs" is also 
common. 

Currently, several methods are used to update software applications. The simplest of 
these is to distribute one entire software application to replace an older one. This method, the 
"full update" method, is simple, but expensive and inconvenient. Typically the software is 
10 distributed on some type of removable media, such as floppy disks or CD-ROMs, which are 
costly to produce and distribute. The time an end user must wait for the removable medium to 
arrive and the time it takes for the software application to install itself on a computer system are 
inconvenient. This inconvenience is compounded where updates occur frequently. Because of 
the large size of software applications it is generally not feasible to distribute such updates over 
15 computer networks, such as the Internet. When full updates are distributed over the Internet, they 
often cause such high loads on servers that other users suffer slow-downs on the network, and the 
servers have trouble meeting the demands. 

In order to bypass many of the problems associated with this type of software updating, 
some software publishers distribute "incremental updates." These updates do not contain entire 
20 software applications, but rather only that information necessary to transform a given version of a 
software application to a newer version. Among the methods available to perform such 
incremental software updating is binary patching, performed by programs such as RTPatch, 
published by Pocket Soft, Inc. A binary patcher replaces only those binary bits of a software 



application which are different in a newer version. Because most software updates involve 
changes to only a small portion of a software application, a binary patcher needs, in addition to 
the old software application, only a small data file including the differences between the two 
versions. The smaller data files distributed for a binary patch update are often less than 1% of 
5 the size of a full update, taking advantage of the large amount of redundancy in the two versions. 
The use of incremental update methods allows for smaller updates which can be 
distributed by means that are not conducive to the distribution of full updates, such as 
distribution over the Internet. The smaller incremental updates also make distribution by floppy 
disk more feasible where a full update would have required many disks, and an incremental 
10 update may require only one. However, incremental update methods introduce another problem: 
the incremental update is specifically useful for updating only one particular version of a 
software application to another particular version. When updates occur frequently, as with virus 
protection software applications, end users may often update from an arbitrarily old version to 
the newest version, skipping over several previously released versions. An incremental update 
15 for the newest version of a software application will update only from the most recent version, 
however. 

One solution to this problem has been for software publishers to group a number of 
bmary patch data files together into one distribution. The user of an arbitrarily old version can 
then apply each incremental update, one at a time, to update to the newest version. However, the 
20 number of incremental updates may be large, due to the fact that the grouping covers a large 
number of versions. The benefits of smaller distributed update files begin to disappear, as the 
; of the grouped-together incremental updates grows. This method of updating applications 
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can also be cumbersome, as a series of update patches need to be selected from the group and 
applied to the software application one after another. 

Another solution to the problem of incremental update version-specificity has been to 
create a unique patch file for transforming every previous version of the application to the most 
current version. Some users may not wish to update their software applications to the most 
current version, however, for a number of reasons. Some may be within a corporate setting, 
where an information services department allows updates only to versions it has had a chance to 
test and approve. Others may have older computer systems which do not support the increased 
resource requirements of the newest version of an application. For these reasons, publishers of 
software updates using this method must generally keep updates available from every previous 
version of an application to a large number of more recent versions. This results in a 
geometrically growing number of update patch files to produce, store and maintain for users. In 
the case of publishers who update their applications frequently, such as publishers of virus- 
protection software applications, this may quickly become untenable. 

One alternative to the methods described above is the use of "push" technology, in which 
servers maintain databases of what versions of a software application each user has. The servers 
then send the necessary updates to each user, as they become available. This system requires 
"smart" servers, however, to monitor user configurations, determine what each user needs, and 
send the appropriate update information. This results in a server-intensive system which can 
cause a drain on server resources comparable to that experienced in the full update scheme, when 
many users are simultaneously requesting full updates. 

What is needed is a system for updating software applications from an arbitrary first 
version to an arbitrary second version which does not require a large amount of information to be 



stored and maintained by a software publisher, does not require the user to acquire a large 
amount of data to perform such an update, and does not require the use of "smart" servers. 
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The present invention is a method and apparatus for distributing the appropriate 
increment software update information to users. A software publisher (118) provides update 
patches (122) which will update users' software applications (110) from one state to another. 
The update patches (122) are "tiered.- Update patches on the ftrs, tier (200) update from a given 
,0 application state to the subsequent application state. Update patches on the second tier (202) 
update an application from a given state to the state which is two versions later. The tier of an 
update patch indicates how many individual updates are spanned by the patch. 

By selectively providing tiered update patches, software publishers (118) can facilitate 
quick, efficient updating of users' applications (110) without producing and maintaining large 
,5 numbers of update patches (122). These update patches (122) may be provided to users 

simultaneously through a variety of distribution channels (124), since a "smart server" is no. 
neeessary to provide users with the needed update patches (122). This allows for selective 
redundancy, as update patches (122) which are likely to be needed by many users may be made 
available through more of the available distribution channels (124) than others, providing a 
20 robust distribution system. 
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Brief Description of the Drawings 



These and other more detai.ed and speeifie objects and features of the present invention 
are more Miy disclosed in the following specification, reference being had ,0 the accompanying 

5 drawings, in which: 

Figure 1 is a block diagram of a first embodiment of the present invention, in which a 
software application 110 on a user's computer 116 is updated with incremental update patches 

1 22 from a remote source 118. 

Figure 2 is an illustration of the relation of various tiers of updates to a series of 

1 0 application states in the present invention. 

Rgure 3 is an illustration of an example of the use of multi-tiered ineremental updates to 
perform a software application update according to the present invention. 

Figure 4 is an illustration of an example of a sub-optimal software application update 

using incremental updates. 
15 Figure 5 is an illustration of an example of apublishing schedule for multi-tiered 

incremenra! updates which meets the necessary condition for optima, updates according to the 
present invention. 

Figure 6 is an illustration of an updating program 126 using a catalog 404 to determine an 
appropriate sequential set of update packages 412 based on attributes of an application 110. 
20 Figure 7 is an illustration of an updating program 126 constructing a sorted directory 408 

of available catalogs 404 from different sources 400 and 402. 
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Figures 8a and 8b are a flowchart showing how an updating program detetntines what 
update patches need to be applied to effect an update, and how the updating program catries out 
the updating. 

5 detailed Description of the preferred Embodiments 

In one embodiment, the present invention may be implemented as an update mechanism 
for a virus protection software application. In other embodiments, the present invention may be 
used to update general computer readable files, which may include data files, program files, 
database files, graphics files, or audio files. For illustrative purposes only, the invention will be 
10 described as embodied in an update mechanism for vims protection software. 

Referring to Figure 1, a virus protection software application 110 winch incorporates a 
number of virus detecting routines 112, and utilizes a number of data files containing virus 
information 114, is installed on a user's compute, 111 Because of the rate a. which new virnses 

created, it is desirable to update the virus protection software applications on the user's 
computer frequently. These updates could take place as often as daily, or even more frequently if 
desired. Generally, these updated applications 110 will include only small changes to the data 
files 1 14, but sometimes larger changes to the vims detecting routines 112 will also be included. 

in order to fully describe the embodiment of the present invention, it is first 
necessary to describe DeltaPackages, DeltaCatalogs, and DeltaDirectories. 
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DeltaPackages 

Each time an updated software applicat,on 110 is produced by the virus protection 
software publisher, the updated form of the software application constitutes a new version. The 
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software publisher uses an incremental update builder, such as binary patch file builder 120, to 
produce a. least one incremental update, such as binary patch ft.. 122, which can transform a 
previous version of the software application to the current version. A binary patch file builder 
HO is a program which takes two versions of a software application, for example versions A and 
B, and produces a binary patch file, 122, which can be used with version A of the software 
application to produce version B. In mis example, version A would be the "source" state and 
version B would be the "destination" state of the application. This binary patch file 122 can 
either be an executable file which acts directly on version A of the software application, or it can 
be a data file which is used by a separate binary patch program (no, shown) to transform version 
A of the software application .0 version B. The binary patch files 122 are stored on an update 
data source 124 (a "server") which makes the patch files 122 available ,o an updater program 126 
(a "client"). The updater program 126 determines what patch files 122 are necessary, retrieves 
them and applies them to the application to be updated 110. In the illustrative embodiment, the 
incremental update files are binary patch files which are digitally signed compressed executable 
modules, and the Java ARchive (JAR) platform-independent file format, available from Sun 
Microsystems, is used for this purpose. Because they are digitally signed, the authenticity of the 
updates can be ensured. When executed, the incremental update file automatically transforms a 
software application from a source state to a destination state. These self-contained executable 
incremental update files conforming to the JAR forma, are referred to as "DeltaPackages" 122, 
) and are one example of what is referred to herein as an "update patch". 

In Figure 2, a series of application states are given, designated state A through state S. 
Each application state is a software application version which is produced by the software 
pubhsher later in time than a version with an alphabetically earlier letter designation. The 
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DeltaPackages 122, which are referred .0 as "tier 1" DeltaPackages 200, are so named because 
th ey each effect a transition from an application state which is oniy one version earlier than the 
destination state. There is a tier , DeltaPackage 200 for updating to each application state other 
than the initial application state, A. The software publisher may produce higher tier 
5 DeltaPackages 122, such as "Tier 3" DeltaPackages 202 and "tier 9" DeltaPackages 204. A tier 3 
DeltaPackage 202 is used to transform an application ftom a source state three versions earlier 
than .he destination state, and a tier 9 DeltaPackage 204 is used to transform an application ftom 
a source state nine versions earlier than the destination state. Many other tiers of DeltaPackages 
122 may be produced, but .he benefits of addilional tiers mus. be weighed against the costs, 
,0 described below. In Figure 2, tier I DeltaPackages 200 are produced for each new version, tier 3 
DeltaPackages 202 are produced for every .hird version, and tier 9 DeltaPackages 204 are 

produced for every ninth version. 

For illustrative purposes, each DeltaPackage 122 is given a designation which is "A" 
followed by .wo letters. The firs, letter indicates the application source state upon which the 
15 DeltaPackage 122 works and the second letter indicates the application destination stale 

produced. For the case where .here are no. multiple "flavors" of the application which need to be 
updated in parallel, a relatively simple process is employed to update the application. 
DeltaPackages 122 are applied to a user's software application incrementally, beginning with the 
highest tier DeltaPackage 122 available which has a source state equal to the current state of the 
20 application, and a destination state no later than the desired ending state. After the DeltaPackage 
,22 is applied, and the application is updated to the destination state of the DeltaPackage 122, 
another DeltaPackage 122 is chosen in the same manner, with the new application state providing 
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th e source state of the next DeLaPackage ,22. This continues unti. the desired ending state of 

the application is reached. 

Figure 3 illustrates this procedure for a case in which it is desired to .ransform an 
apphcarion of state F to an apphcation of state T. Following the procedure described above, 
such a transformation is accontp.ished through only four incrententa, updates, from F to G to J to 
S to T. Each time a new Del.aPackage 122 is to be selected, the one chosen is the highest tier 
DehaPackage .22 with the current application state as a source state, and a destination state 
which does not exceed the desired ending state. . 

When fewer tncremental updates are required to perform a given transformation, fewer 
DeltaPackages .22, and therefore less information, needs ,0 be transferred to the application. 
The procedure described above produces a desired transforation using the smallest number of 
available DeltaPackages .22, as long as one condition is me,: no availab.e DehaPackage ,22 
naay have a source state which is between the source and destination sUr.es of an available 
Del.aPac.tage ,22 with a lower tier. As long as this condttion is met, then the procedure 
described above will perform an optimum transfonrrauon, using the smallest number of avai.ahle 
DeltaPacltages ,22 to get ftom the beginning state to ,he desired ending state. If the condition is 
not me. men the procedure described above may result in a transformation which uses more of 
ft. available DeltaPackages ,22 man necessa^. An example of a snb-opttma. transformation is 
iUustrated in Figure 4. In that case, a transforation from state G to state S uses four 
0 DeltaPackages 122 (AGJ, AJM, AMP and APS), when it need only use three (AGH, AH,, and 
MS). Because .he A,S De.taPackage ,22 has a source state (,) which is between the source and 
destination states of a lower tier DehaPackage (AGJ), the A,S DeltaPackage ,22 violates the 
above condition, and a sub-optima, se, of DeltaPackages ,22 is used. In praCice, a software 
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pusher may easily ensure ,ha, the available DehaPackages ,22 mee, this condition, since each 
DeltaPackage .22 is produced later in time than trackages "» — 
st a,es. to ,he above example, before issuing DeltaPackage MS, the publisher would elmhnate 
DeltaPackage AGJ and possibly rep.ace il wi.h another, such as DeltaPackage AGI. 
5 ,„ the example of Figure 3, if only the tier 1 DeltaPaclcages 200 had been availab.e, 

fourteen DehaPackages .22 would have been required for the transformation, instead of four, 
and much unnecessary information would have been transferred to the application. The total 
number of DehaPackages .22 which would have been produced by .he publisher, however, 
would have been smaller, the higher her DeltaPackages 122 no, having been produced. On the 
,0 other hand, if a tier .4 DeUaPackage .22 designated AFT had been available, only one 
DeltaPackage .22 would have been required, and very little information would have been 
kerned ,o Ore user. However, the availability of a DeltaPackage ,22 which accomp.ishes any 
particular .reformation in one step can be assured only by producing individual DehaPackages 
m from every source srate .o every des.ina.ion s.ate, which requires a number 
,5 .22 approaching N! (where N is the number of file states,. Producing and maintaining such a 
,arge number of individual DehaPackages .22 is no. feasible in many situations, as explained 
above. These considerations must be oonsrdered by a software publisher in detennining the most 
efficient DeltaPackage .22 publishing schedule. For .he illustrative embodiment, it was 
de ,ennined .hat providing DehaPackages .22 of tiers 1, 3 and 9 wou.d be mos. eff.cient. 

The tiers of DehaPackages ,22 produced do not need to be published according ,o any 
fixed schedule, but rather may be determined as new updates become available. In Figure 5 an 
nregnlar publishing schedule of DehaPackages ,22 is shown. There am four separate tiers of 
DehaPackages 122 available wfth J as a source state. The decision to create so many 
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Dockages ,22 with .he same source state maybe based on the fae, tha, many copies of.be 
appfication in .be J state are known to be at ,ar g e. Many publisher-specific, application-specific, 
and information tra^por, mechanism-specific factors wiU affect .be desirabUUy of a publishing 
schedule for DeltaPackages 122. 

5 

DeltaCatalogs 

Software pnblishers often produce different "flavors" of a single software application, 
directed to different computer arehi.ec.ures, different operating systems, and users who speak 
different languages. The scheme for pubbshing incremental updates .aid ou. above is adequate 
,0 for the case in which there is on.y one flavor of a software application. For the more general case 
of several application flavors, however, some additional mechanisms ean be used to handle the 
adduiona, complexities of parallel updating. A system which addresses these complexifies is 
described in the second illustrative embodunen. of the present invention. 

to the case of virus definition updates, there are often updates which are not operating 
15 system-specific, and sometimes there are updates which are no. even computer architecture- 
specific Other times, updates are specific to these, and other, categories. A single update 
DeltaPaekage ,22 may be useful to update some flavors of an application, but no. others. To 
handle these complexifies, update catalogs, referaed to as "DeltaCatalogs," are utilized. These 
update catalogs are another example of what are referred to herein as "update patches." Rate 
20 than having a single DeltaPaekage 122 correspond to each incremental update (i.e. "AIS") as 
above, a DeltaCatalog corresponds to each incremental update (i.e. «A,S"). Each DeltaCatalog 
has an associated source state and an associated destination state, and specifies the necessary 
update information by specifying which DeltaPackages ,22 should be used by each flavor of the 
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app.ica.ion ,o update from .he source s<a,e .0 .he destination s.a.e. In one embodiment, 
D*W»- unique IDs which do no. conform .0 ,he «AAB" forma, used above 
for tUus.ra.ive purposes, and are specified by the DeUaCatogs using rnese untque IDs. With 
D e„aCa,,og S subs.i.u,ed for DeUaPackages .22, the genera, scheme described above is unfiled. 

There are a number of different ways DehaCatalogs can be implemented. In this 
embodiment, the Ex.ensib.e Markup Language (XML) standard is used to create a document type 
definttion. The XML standard is avai.ab.e from W3C Publications, Worid Wtde Web 
Consortium, Massachusetts Institute of Techno.ogy, Laboratory for Computing Sciences, NE43- 
356, 5 45 Techno.ogy Square, Cambridge, MA 02,39. An examp.e document type definttion 
corresponding ,0 the XML standard, referred .0 as DPML (for DehaPackage Markup Language), 
i8 given in Appendix A. In mis document type definition, .here are anumber of types of entries a 
De.raCaUr.og may contain. These types are Product (.he type of software application), Package 
(a specific DeltaPackage 122), OS (operating system), CPU (computer architecture) and 
Language (the language spoken by the users of the software application). An entry of any of 

or Language. None of the entry types may contain a De.taCaUr.og, and the Package must contain 
a„ "ID" which corresponds to a specific DeltaPackage 122. Also, the "to", or des.ina.ion state, 
data field and me "from", o, source state, data field must be given for a De„aCa,a.og. 

An example of a De.taCata.og contained in a file written .0 conform ,0 me XML forma. 
0 ,s given in Appendix B. In me De.taCaralog f,.e i.se,f, the documen. type definition for "DPML" 
is specified by inc.uding a uniform resource ,oca.or (URL, pointing .0 me ,oca.ion of a current 
specification of the documen. type definition. A,.ema.ive,y, .he data ,ype definition may be 
induderi in me fi.e exp.icitty. A software app.ica.ton .0 be updared contains .he attribu.es of 
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m which need .0 be app.ied to .he software a P p,iea«o„ .0 effect the transformation from the 
cutT e„, state to the desired ending state, an updating mechanism, referred ,0 as a "DeUaUpdater" 
is used. The DeitaUpdater may he a separate prog™, or tnay he par, of the software appficatton 
ils ,,f. ,, goes through the same hasic procedure cutanea ahove, with DehaCaralogs taking the 
plac e of DeUaPackages ,22. The De.taCatalog of the highest tier available which has a "ftom" 
Held matching the application's curren, srate and which has a V Ud which does no, exceed 
the endrng state is selected by the DeitaUpdater. The DeltaCatalog is then processed, with .he 
DeltaUpdater processing only .hose sub-entries contained within entries with aftribu.es which 
ra a,ch,hoseof.heapp,ic,,on. An example is illustrated inHgureb. The De.taCa.alog 404 
contains a simpUfted form of.be informatton contained in the De.taCa.alog fi.e of Appendrx B. 
AppHcafion 110 has the atftibu.es of "NAV version 2.0 running on Windows NT on an alpha 
computer using Norm America English." Tbe DeitaUpdater 126 wou.d pnocess only Package 
1D . S «4 8 7" and "766," as al. other Package entries correspond to different attributes. Those 
DeltaPackages ,22 which correspond to these two IDs wou,d then make up a sequential set 4,2 
of DeftaPackages ,22 .0 be applied to application ,10 in .be order they were encountered in 
De,taCa«a,og 404. When applted to apphca.ion „0, me DeftaPackages ,22 of se, 4,2 transform 
application „0 from state 1 ,0 state 8, the states given in the "from" and "to" fields of 
0 DehaCatalog 404. ,f the desired end.ng state were still later than state 8, .hen mis procedure 
would again be applied ,0 seiect and process another DeUaCatalog 404, one which has a "from" 



value of 8. 
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T-vltflDirectories 

A number of transfer mechanisms are available to a DeltaUpdater for retrieving 
D e„aCa,a,ogs and DeUrfackages .22. Among tbese are ,he NNTP Usenet server pro.oco,, 
ava „ab,e from Internic as -Revest For Comments 977"; tbe HTf P protoco,, available from 
,n,er„ic as -Reaueat For Comments 1945"; the FTP protocol, available from In.erntc as "Reaues, 
For Common. 959"; and diree, aceess ,o a «n.e served nsing a protoeo. snch as the Universa, 
Naming Convention (UNC). A file server may be, among other things, interna, disk rnefc 
removable d,sk media, or a network resource. Other distribution mechanisms axe currently 
available and more wil, likely bo available in the future. Al, that is required of a transfer 
onanism is that the mechanism be able to snpp,y computer readable data upon ,e,ues<. The 
present invention utilizes so called "dumb media," meaning that the medium supplying the 
req ues,eo information need no. interact with the DeKaUpdater beyond simply supplying 
req ues,ed data. Specifically, "smart servers," such as those used in "push" tecnnology, are no, 
necessary. A smart server determines what update information is necessary, given information 
about the state of the software application, and then supplies that information. The described 
transfer mechanisms allow De.taCaU.ogs and DeUaPackages .22 ,0 be retrieved from "cata.og 
sources" and "update data sources" on which they are stored. 

A typica. system embodying the present invention wi.l have available more than one of 
to mentions transfer mechanisms, as illustrate, in Figure 7. A DeltaUpdater 126 wft, have 
„ access to a .is, 403 of .ocations, spectfted as URLs, where needed da,a may be found. In genera,, 
,bese URLs wi„ spec.fy a number of NNTP news-servers wi,h news-groups, HTTP servers with 
directory pa«hs, FTP servers wi,h directory pams, and f„e servers wfth directory pa,hs. b the 
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e—iHu^inF^^.anNNTPse^^^ames.ver^ con—, 
DeltaCatalogs 404. 

The flowchart of Figure 8 shows the steps carried „u. h y the De.uUpda.er ,2*. When an 

5 found which contains the reared DeUaCata.ogs 404. The DeUaUpdater 126 bui.ds a 

-MtaDi W 408, which is a hst of avai.ab.e DeUaCata.ogs 404 at the specification. For 
transfer mechantsms which support prying of a ffle dtrectory, such as HTTP, FTP and fi.e 
servers, the DeUaDtreCory 408 is constructed with .he infonnatton relumen hy such queries. For 
these .ransfer mechanisms, .he De,,aCata.og 404 source and destination state information is 
,0 contained in the - of each DehaCataiog ffle. DeUaCata.ogs 404 are nanted according to a 
scheme where the firs, four characters specify a source s<a.e, the next four characters specify a 
destination state, and the f,e extension is "cat." For NNTP, .he DeUaUpdater !26 retrieves 
headers for avaflab.e messages, and ,ooxs for DeUaCa.a,og information in the headers. The 
D e,,aCa,a,og tnfo.ma.ion specifles tha, .he message is a DeUaCataiog 404, and speciftes the 
15 source and destination states are for the DeUaCataiog 404. 

After retneving the source state and destinalion slate for each available DeUaCataiog 404, 
the DeUaUpdater 126 organizes thts information in the Directory 408 hy sorting 504 the 
D e lt aCa,a,ogs 404 first hy source state, and next hy reverse destination state. The De„aCata,ogs 
404 of the preferred transport mechanism are used, if possib.e. Olhervrise, DeitaCatalogs 404 of 
20 aUemate transport mechanisms are usee. This ordering of the De.taCata.og 404 information 
aflows the DeUaUpdater .26 ,o move through the DeUaDtreCory 408 efficient.,, finding the 
URL of each De«aCa,a,og 404 with the necessary source state, and .he farthest delation state 
which does no, exceed the desired ending state. The DeUaUpdaler 126 determines 506 the 
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enrren. state of the app.ication to be updated, and the desired ending state of the app.ie.tion. The 
appHcation can supp.y its current state to the DeUaUpdatet ,26, bo, the DeUaUpdater ,26 needs 
otbe, information to detemtine the desired ending state. The nterhod by wh.ch the DeUaUpdater 
,26 determines the desire ending state of the application is addressed be,ow. 
5 The sequential set 4,2 of DeUaPackages 122 is cleared ou, 508, in preparation for the 

determination of the set 4,2. The DeltaUpdater ,26 moves through the Directory 408 
sequent,* in Ore ,oop composing steps 5,0, 5,2, and 5,4 to find the first DehaCatalog 404 in 
,he DeUaDirectory 408 which has the current state as a source state. The DeUaUpdater .26 men 
moves through the Directory 408 from this De,,aCa,a,o g 404 to find the De„aCata,og 404 
,0 which has the farthest destination state which is no, beyond the desired ending state (loop 5.6, 
5,8, and 520). If al, of the De.taCata.ogs 404 which have the — state as a source slate have 
a destination state which is beyond the desired ending state, then the update will fail (step 522). 

When a DeltaCatalog 404 is identified at 516 which has a destination state which is not 
beyond the desired ending state, the DellaCatalog 404 is requested 524 from the appropriate 
, 5 source 400 or 402. After the requested DeltaCatalog 404 is received 526, the DeltaCatalog 404 
is processed 528, as described above, to determine an mcrementa, se, of DeUaPackages .22 
which are appended to .he sequential se, 4.2. The current state of the app.ication is then se. 530 
t0 .he dest.na.ion state of this Del.aCa.alog 404, and if that state is no, the desired ending state 
532 the processing continues a, s.ep 514, and another De.taCa.alog 404 is determined. 

When .he ft... sequentia, se, of DeltaPaekages 122 necessary for an update are determined 
532, the De..aUpda,er 126 requests 534 each needed De.taPackage .22. The DeUaUpdater .26 
receives 536 the requested DeUaPackages 122 using the appropriate pro.oco., then uses the 
digital signature to verify «ha, the DeUaPackages .22 are authentic and have not been aUered. 
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Each DeltaPaclcage 122 retrieved is executed in sequence 538, transforming the application from 
the beginning state to the desired ending state, and the method stops at step 540. In other 
embodiments, the DeltaUpdater 126 retrieves all of the DeltaPackages 122 specified by a 
DeltaCatalog 404 before moving on to the next DeltaCatalog 404. 
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TVltaDirectives 

The beginning state of an application update is determined by .he De.taUpda.er with 
reference to .he application Ut which wU, carry some designation of the curren, state. The 
desired ending state, however, is no, necessarrly as easy to identify. One possibi.ity wou.d be for 
,0 .he DeKaUpdater .o simply upda,e .he application to the latest state for which De..aCa,a,ogs are 
available. In many situations, however, it may not be desirable to the user of a software 
application to update .he application to the la.es« available state. For example, in corporate 
settings, information Services departments may wish to .est out and verify the stability of a 
version of a software application before allowmg .he applications owned by .he corporation to be 
,5 updated .0 tha. version. This is often the case when .he update is a major revision. Also, some 
ne.wor.ced computer systems may require .ha. all copres of a particular application be a, exactly 
ft. same state. One solution wou.d be for an Information Services department ,0 control the 
availability of Del.aCata.ogs 404. Alternatively, it is desirable in some situations to utilize 
^Directives," which are issued in connection with a given computer or network, specifying 
20 to which destination state an update is allowed. A De.taDirective is a file or NNTP message 
containing a single value, the allowed destination state. The filename or NNTP message header 
identifies .he file or NNTP message as a DeltaDimctive. The location for such DettaDirectives is 
m ade available to the DeltaUpda.er before .he update procedure is begnn. As illustrated in 
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Figure 7, the De,.aUpda.er ,26 identifies .he Utes. availab.e DeltaD.rective 405 in tire prescribed 
.oeation, obtains .he De.taDirective 405, and reads .he desired ending state from it This desired 
ending state is used by tire Dei.aUpda.er 126 in steps 506, 5!6, and 532 of Fignre 8. The 
pnbhsher of the npdates may make available genera. DeltaDirectives 405 whieh specify the tatest 
available state. The DeltaUpdater for any given computer may be set to look to the 
DeltaDirectives 405 issued by the software publisher or those issued by some other authority, 
such as an Information Services department. 

The above description is included to illustrate the operation of tire preferred embodiments 
and is no. mean, to timi. the scope of the invention. The scope of the invention ,s .0 be limited 
only by the following claims. From the above description, many variations will be apparent to 
one skilled in the art that would yet be encompassed by the spirit and scope of tire presen. 



invention. 
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